Demo 很好、實際用很糟
一個工程師花了三個週末，把公司的客服流程接上了一個 agent：能回答基本問題、會查資料庫，在 demo 裡看起來很厲害。
然後他把它交給同事實際用。結果：任務稍微複雜一點，agent 就跑偏；執行程式碼的時候有兩次差點動到不該動的資料；任務結束之後什麼都不記得，下次要從頭說。
他找到的問題不是模型不夠強，是底層的執行架構沒有設計來「真正交差」。
這個場景的問題有個結構性原因：大多數開源 agent 框架的設計出發點是「讓 AI 能查資料、生成報告」，也就是說，它們假設任務是線性的、單一的、輸出是文字的。這個假設在 demo 夠用，但在稍微複雜一點的生產環境就開始破裂。
DeerFlow 2.0 選擇從不同的假設出發。
Ground-Up Rewrite：方向改變不是功能升級
ByteDance 在 2026 年 2 月 28 日正式發布 DeerFlow 2.0，官方 README 明確說這是 ground-up rewrite——與 v1 完全不共用程式碼。v1 仍在 main-1.x 分支維護，但活躍開發已全面轉移到 2.0。
這個措辭值得重視。Ground-up rewrite 代表的不是「v1 加了幾個功能」，而是設計哲學的根本轉換。
v1 的定位是 deep research agent：AI 接收一個問題，透過搜尋和工具查資料，最後生成一份報告。這個模式對研究類任務夠用，但它假設任務是單人可完成的，執行過程是線性的，輸出是一個文件。
2.0 把自己定位為 open-source super agent harness。harness 這個詞的選擇很準確：它不是一個會自己做事的工具，而是一個讓多個 agent 協作、安全執行、有記憶的執行框架。設計假設從「AI 回答問題」變成了「AI 帶著一個小組完成一個任務」。
這個方向轉換決定了它能解決哪些問題。
四個核心能力對應四個生產問題
這張插圖幫助讀者更快理解〈四個核心能力對應四個生產問題〉中的差異與對比。
DeerFlow 2.0 的核心能力組合——sub-agents、sandbox、memory、skills/MCP——每一個都對應一個「沒有它就會撞牆」的場景。
Sub-agents：任務太大，一個 agent 跑不完
複雜任務通常不是一個 agent 能從頭跑到尾的。比如你想讓 AI 做一個市場分析：要分別查不同來源的資料、要做計算、要比較不同角度的結論、最後要整合。如果全部塞給一個 agent，它要嘛跑偏、要嘛超過 context 限制、要嘛花很長的時間在你不需要它等待的步驟上。
Sub-agents 讓任務可以被分解：一個 orchestrator agent 拆任務，分配給各自專職的子代理並行跑，最後收攏結果。這不是把一個大 prompt 拆成小 prompt，而是真正的並行任務執行架構。
Sandbox：執行程式碼時不能污染生產環境
讓 AI 執行程式碼一直是個高風險操作：萬一它刪了不該刪的東西、寫入了不該寫入的地方、或者 code 有 bug 直接爆掉，在沒有隔離的環境裡後果不可控。
Sandbox 提供隔離的執行環境，讓 AI 跑的程式碼在一個受控的邊界裡運行，不影響主系統。這是讓 agent 從「可以在 demo 裡執行程式碼」升級到「可以在生產環境裡執行程式碼」的前提條件。
Memory：下一個任務不應該什麼都不記得
大多數 agent 實作的記憶是 session 層級的：任務結束，記憶消失。下一個任務你要從頭說一遍。對單次任務這沒問題，但對一個真正在跑工作流的 AI 系統，這意味著它永遠無法從累積的操作經驗裡學習，也無法在跨任務之間維持一致的上下文。
Memory 讓跨任務的上下文可以持續存在——它知道上次你說的那個資料來源是什麼、你的偏好是什麼、某個任務的中間結果是什麼。這讓 agent 從「有問必答的工具」往「有記憶的執行夥伴」的方向移動。
Skills 和 MCP 工具擴展：核心不應該因為加工具而變複雜
工具擴展一直是 agent 框架的痛點：要加一個新工具，往往要改核心邏輯、重新測試整個流程。Skills 機制讓工具擴展透過模組化的方式進行，不需要碰核心程式碼；MCP（Model Context Protocol）的支援讓整合外部工具有了標準化的介面。
這兩個機制合在一起，讓「加工具」和「維護穩定性」不再是衝突的要求。
MIT 授權和版本成熟度：誠實評估
MIT 授權是這個框架的重要條件之一。MIT 允許你使用、修改、散布、商用，對有在考慮內部部署或把 DeerFlow 整合進產品的團隊，這個授權是一個非常低的法律門檻。
但有一件事需要誠實說明：DeerFlow 2.0 目前在 GitHub 上沒有正式的 release tag 或 release artifacts。版本發布的主要證據來自官方 README 的自述和 repo 的活躍狀態，以及一個可追溯到 2026 年 1 月 21 日的 v2 規劃 issue。
這不是說 2.0 不存在或不能用，但它的意義是：版本管理的制度化程度還不高。對想要追蹤「我部署的是哪個版本、下次升版會破壞什麼」的生產環境而言，這是一個需要自行管理的風險。
GitHub Trending #1 的數字說明社群關注度，但關注度不等於生產穩定性。這是兩件要分開判斷的事。
三種團隊，三種建議
場景簡單、輸出文字就夠：暫時不需要
如果你的 AI 任務是「給我生成一份摘要」「幫我寫一封信」「回答這個問題」，DeerFlow 2.0 是過度設計。它的架構複雜度是為了多代理協作、沙箱執行、跨任務記憶這些需求存在的，這些需求在簡單場景裡不會出現，只會帶來不必要的維護成本。
任務複雜、需要多步驟執行：現在可以評估
如果你的場景是「AI 要能拆任務、並行處理、執行程式碼、記住上一次做了什麼」，DeerFlow 2.0 是目前最值得在清單上的開源選項。MIT 授權讓試用成本低，可以先在隔離環境裡跑 PoC，評估它的架構是不是符合你的需求，再決定要不要進一步整合。
值得在 PoC 階段就確認的問題：你能不能接受目前無正式 release tag 的版本管理方式？你的團隊有沒有能力在 framework 出問題時自己追源碼？
正在自己拼裝 infra：最值得試
如果你現在的狀態是「自己把 LangChain + 某個 memory 方案 + 某個 sandbox 工具拼在一起，但維護成本越來越高」，DeerFlow 2.0 把這些整合在一個框架裡，能減少你自行整合的成本。不保證它比你的拼裝方案更好，但它能讓你把架構決策的精力從「怎麼把這幾個工具串起來」移到「怎麼設計任務流程」。
ByteDance 沒有發布一個 demo，他們選擇了一個更難的路徑：重寫一個框架，讓它能做的事從「回答問題」升級到「交差」。這個選擇對不對，要等更多生產部署的案例來驗證。但這個方向，和現在整個 agent 市場在問的問題是同一個方向。